…3507)

## Description

Makes four tests robust to running serially with pytest-xdist disabled
(`-n0`). They pass under the normal xdist test run but fail under `-n0`,
which is how the backwards-compatibility CI check (#3506) runs a
previous release's database suite against the current schema.

- **Three script tests** (`test_equivalents`, `test_novelist`,
`test_search`) constructed a `Script` with no `cmd_args` and called
`do_run()`, so the script's argparse fell back to `sys.argv[1:]`. Under
xdist each worker has a clean execnet `sys.argv`, but under `-n0`
`sys.argv` is the real pytest command line. That caused argparse to
error on unrecognized arguments (`equivalents`, `novelist`), and the
leaked `-m db` marker matched `RebuildSearchIndexScript`'s
`-m/--migration` flag, sending it down the migration path so
`search_reindex.delay` was never called (`search`). Each now passes an
explicit `cmd_args=[]` to express "no arguments" independent of
`sys.argv`.
- **The OIDC logout test**
(`test_oidc_logout_initiate_no_stored_id_token`) asserted on `caplog`
without setting a capture level. Under serial execution the effective
log level is left raised by an earlier test, so the warning was not
captured and `caplog.text` was empty. It now sets the level explicitly,
matching its passing sibling
`test_oidc_logout_initiate_revocation_only`.

No production code changes — scripts intentionally default `cmd_args` to
`sys.argv` for real CLI use via `Script.run()`.

## Motivation and Context

The backwards-compatibility check added in #3506 runs the previous
release's `-m db` suite under `-n0` (external-schema mode requires
serial execution — the single shared database can't be used by parallel
xdist workers). Its first real run surfaced these four latent
test-isolation bugs, which xdist had been masking. None are
schema-compatibility failures; all four fail identically against the
previous release's own schema. Fixing them here means that once a
release containing these fixes becomes the "previous release", the check
will pass against it.

## How Has This Been Tested?

Reproduced the failures on the unfixed tests by running them under `-n0`
in the docker test environment (`tox -e py312-docker -- -n0 ...`),
observing the argparse `unrecognized arguments` errors. With the fixes
applied, all four pass under `-n0` (including with `-m db` present,
which exercises the `search` flag-collision case): `60 passed, 19
deselected`.

## Checklist

- [x] I have updated the documentation accordingly.
- [x] All new and existing tests passed.

## Description

Fixes the `backwards-compatibility-test` job, which has been failing on
`main` since #3506 merged, with:

```
no such service: redis
##[error]Could not start service containers.
```

`docker/ci/test_backwards_compatibility.sh` asked docker compose to
start a `redis` service. #3498 renamed that compose service to `valkey`.
This renames the reference.

The service is still needed, so this is a rename rather than a removal:
`initialize_instance` itself only takes a Postgres advisory lock, but
the `webapp-prev` container inherits `PALACE_TEST_REDIS_URL:
redis://valkey:6379/3` from the `webapp` service, so the container has
to be up for the previous release's test run. The `redis://` URL scheme
and the `PALACE_*REDIS*` variable names are deliberately left alone,
consistent with #3498 — they name the protocol, not the instance.

## Motivation and Context

#3506 was branched off `main` before #3498 landed, and was never
rebased. At #3506's head commit `docker-compose.yml` still defined a
`redis` service, so the script was correct on the branch and the job
passed there. The two PRs touch disjoint files, so git merged them
without a textual conflict — the conflict was semantic, and nothing
surfaced it until the job ran on `main`.

This also means the `push` job, which now depends on
`backwards-compatibility-test`, is blocked on `main` until this lands.

## How Has This Been Tested?

Reproduced the failure and confirmed the fix locally with `docker
compose ... up --dry-run`, which validates service names without
starting containers:

- with the old `redis` argument: exit 1, `no such service: redis` — the
identical message from the failing CI log.
- with the new `valkey` argument: exit 0.

Then started the service for real and confirmed it reaches `healthy` and
that `valkey-cli ping` answers `PONG`.

I did not run the script end-to-end locally, since that requires pulling
both the current and previous release images and running the full
`pytest -m db` suite. Worth flagging for review: this fix unblocks a
step that has never actually executed, because the previous release's
test suite will now run against Valkey for the first time — on #3506's
branch it only ever ran against `redis/redis-stack-server`. I expect
that to be fine (Valkey is protocol-compatible, `main`'s own db suite
already passes against `valkey:9.0` in the tox stack, and the previous
release's Redis usage is core commands only), but this job is where that
combination gets exercised first. The job runs on non-tag refs, so this
PR's own CI is the real verification.

## Checklist

- [x] I have updated the documentation accordingly.
- [x] All new and existing tests passed.